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Abstract 


This document specifies the algorithms, algorithms’ parameters, 
asymmetric key formats, asymmetric key size, and signature format for 
the Resource Public Key Infrastructure (RPKI) subscribers that 
generate digital signatures on certificates, Certificate Revocation 
Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and 
certification requests as well as for the relying parties (RPs) that 
verify these digital signatures. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by 

the Internet Engineering Steering Group (IESG). Further 
information on Internet Standards is available in Section 2 of 

RFC 7841. 


Information about the current status of this document, any 
errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7935. 
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1. Introduction 
This document specifies: 
* the digital signature algorithm and parameters; 
* the hash algorithm and parameters; 
* the public and private key formats; and, 
* the signature format 


used by Resource Public Key Infrastructure (RPKI) [RFC6480] 
subscribers when they apply digital signatures to certificates and 
Certificate Revocation Lists (CRLs) [RFC5280], Cryptographic Message 
Syntax (CMS) signed objects [RFC5652] (e.g., Route Origin 
Authorizations (ROAs) [RFC6482] and manifests [RFC6486]), and 
certification requests [RFC2986] [RFC4211]. Relying parties (RPs) 
also use the algorithms defined in this document to verify RPKI 
subscribers’ digital signatures [RFC6480]. 


The RPKI profiles and specification documents that reference RFC 6485 
now refer to this document; these documents include the RPKI 
Certificate Policy (CP) [RFC6484], the RPKI Certificate Profile 
[RFC6487], the RPKI Architecture [RFC6480], and the Signed Object 
Template for the RPKI [RFC6488]. Familiarity with these documents is 
assumed. 


1.1. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
2. Algorithms 
Two cryptographic algorithms are used in the RPKI: 
* The signature algorithm used in certificates, CRLs, CMS signed 
objects, and certification requests is RSA Public-—Key 
Cryptography Standards (PKCS) #1 Version 1.5 (sometimes 


referred to as "RSASSA-PKCS1-v1_5") from Section 8.2 of 
[RFC3447]. 
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* The hashing algorithm used in certificates, CRLs, CMS signed 
objects and certification requests is SHA-256 [SHS] (see note 
below). 


NOTE: The exception is the use of SHA-1 [SHS] when CAs generate 
authority and subject key identifiers [RFC6487]. 


In certificates, CRLs, and certification requests the hashing and 
digital signature algorithms are identified together, i.e., "RSA 
PKCS #1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The 
Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST 
be used in these products. 


The OID is in the following locations: 


In the certificate, the OID appears in the signature and 
signatureAlgorithm fields [RFC4055]. 


In the CRL, the OID appears in the signatureAlgorithm field 
[RFC4055]. 


In a certification request, the OID appears in the PKCS #10 
SsignatureAlgorithm field [RFC2986], or in the Certificate Request 
Message Format (CRMF) POPOSigningKey algorithmIdentifier field 
[RFC4211]. 


In CMS SignedData, the hashing (message digest) and digital signature 
algorithms are identified separately. The object identifier and 
parameters for SHA-256 (as defined in [RFC5754]) MUST be used for the 
SignedData digestAlgorithms field and the SignerInfo digestAlgorithm 
field. The object identifier and parameters for rsaEncryption 
[RFC3370] MUST be used for the SignerInfo signatureAlgorithm field 
when generating CMS SignedData objects. RPKI implementations MUST 
accept either rsaEncryption or sha256WithRSAEncryption for the 
SignerInfo signatureAlgorithm field when verifying CMS SignedData 
objects (for compatibility with objects produced by implementations 
conforming to [RFC6485]). 


3. Asymmetric Key Pair Formats 


The RSA key pairs used to compute the signatures MUST have a 2048-bit 
modulus and a public exponent (e) of 65,537. 
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4. 


1. Public Key Format 


The subject’s public key is included in subjectPublicKeyInfo 
[RFC5280]. It has two sub-fields: algorithm and subjectPublickey. 
The values for the structures and their sub-structures follow: 


algorithm (which is an AlgorithmIdentifier type): 
The object identifier for RSA PKCS #1 v1.5 with SHA-256 MUST be 
used in the algorithm field, as specified in Section 5 of 
[RFC4055]. The value for the associated parameters from that 
clause MUST also be used for the parameters field. 


subjectPublickey: 
RSAPublicKey MUST be used to encode the certificate’s 
subjectPublickey field, as specified in [RFC4055]. 


-2. Private Key Format 


Local policy determines the private key format. 
Signature Format 


The structure for the certificate’s signature field is as specified 
in Section 1.2 of [RFC4055]. The structure for the signature field 
in the CMS SignedData’s SignerInfos is as specified in [RFC5652]. 


Additional Requirements 


It is anticipated that the RPKI will require the adoption of updated 
key sizes and a different set of signature and hash algorithms over 
time, in order to maintain an acceptable level of cryptographic 
security to protect the integrity of signed products in the RPKI. 
This profile should be replaced to specify such future requirements, 
as and when appropriate. 


The procedures to implement such a transition of key sizes and 
algorithms are specified in [RFC6916]. 


Security Considerations 


The Security Considerations of [RFC4055], [RFC5280], and [RFC6487] 
apply to certificates and CRLs. The Security Considerations of 
[RFC2986], [RFC4211], and [RFC6487] apply to certification requests. 
The Security Considerations of [RFC5754] apply to CMS signed objects. 
No new security threats are introduced as a result of this 
specification. 
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7. Changes Applied to RFC 6485 


This update includes a slight technical change to [RFC6485] that is 
considered to be outside the limited scope of an erratum. The 
document update process has included other errata and also corrected 
a number of nits. 


Section 2 of [RFC6485] specified sha256WithRSAEncryption as the OID 
to use for the SignerInfo signatureAlgorithm field in CMS 
SignedObjects. However, existing implementations use the 
rsaEncryption OID for this field. (Support for rsaEncryption in 
third-party cryptographic libraries is better than 
sha256WithRSAEncryption, perhaps because [RFC3370] says that support 
for rsaEncryption is required, while support for OIDs that specify 
both RSA and a digest algorithm is optional.) 


Rather than force existing implementations to switch to 
sha256WithRSAEncryption, this document was changed to follow existing 
practice. This does not represent a cryptographic algorithm change, 
just an identifier change. (Unlike certificates, CRLs, and 
certification requests, CMS signed objects have a separate algorithm 
identifier field for the hash (digest) algorithm, and that field is 
already required to contain the id-sha256 OID per Section 2.) 


To avoid compatibility problems, RPs are still required to accept 
sha256WithRSAEncryption if encountered. 


Other changes include: 
* Minor wording and typo fixes. 


* Corrections to references ([RFC5652] instead of [RFC3370], 
[RFC3447] instead of [RFC4055]). 


* Additional citations included in the Introduction. 


* Correction to the CRMF POPOSigningKey field that is mentioned 
in Section 2 (algorithmIdentifier instead of signature). 


* Inclusion of certification requests in mentions of 
certificates, CRLs, and CMS signed objects. 


* Replacement of text in Section 5 with a pointer to the 
procedures specified in [RFC6916] (algorithm agility). 


* Replacement of "Signed object" with "CMS signed object" 
everywhere. 
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